home *** CD-ROM | disk | FTP | other *** search
/ Network Support Library / RoseWare - Network Support Library.iso / unix / lwprpl.txt < prev    next >
Internet Message Format  |  1991-07-04  |  9KB
  1. Date:         Tue, 2 Jul 91 12:42:18 PDT
  2. Reply-To: Novell LAN Interest Group <NOVELL%SUVM.BITNET@uga.cc.uga.edu>
  3. From: Brian Meek <brian%CA.NOVELL.COM@uga.cc.uga.edu>
  4. Subject:      Re: LAN WorkPlace on a server
  5. X-To:         novell@suvm.acs.syr.edu
  6. To: Multiple recipients of list NOVELL <NOVELL@SUVM>
  7. In-Reply-To:  <9106272043.AA02101@newsun.novell.com>; from "BARKER" at Jun 27,
  8.               91 4:37 pm
  9. Status: OR
  10.  
  11. Once upon a time, Scott Barker wrote:
  12.  
  13. > Could anoyone share with us what "clever" work we have to do to run Lan
  14. > Workplace from a server volume?  I just installed it on a single PC and it
  15. > took a fair amount of time.  Our campus has the education site license so
  16. > I'd like to install it on a bunch of machines.  Putting things on the
  17. > server once would obviously save a LOT of work.  From Brian's message it
  18. > sounds like just copying the files to directories on the server isn't
  19. > sufficient.  What else needs to be done?
  20.  
  21. Since then, numerous others have reiterated the question...
  22.  
  23. I really haven't meant to avoid this issue, but I was hoping to get the
  24. time to write up this procedure in a very detailed and concise fashion...
  25. Since I have no such time, here's a quick shot at it to point people in
  26. the right direction.
  27.  
  28. First, a few basics about LAN WorkPlace for DOS and its underlying TCP/IP
  29. stack.  All of the executable files in the package are placed by the
  30. install procedure in DRIVE_LETTER:\XLN\BIN40.  All of these files can be
  31. placed in a read-only public directory and mapped to a NetWare search
  32. drive.
  33.  
  34. Additional files that contain application default values and various
  35. (possibly user and station specific) configuration values are found in a
  36. collection of directories under DRIVE_LETTER:\XLN and, this is key: are
  37. located by the environment variable "EXCELAN".  For example, on my
  38. system, the EXCELAN environment variable is set to "C:\XLN", and the
  39. following files are found and used by the applications:
  40.  
  41.      C:\XLN\TCP\RESOLV.CFG        DNS server list.
  42.      C:\XLN\TCP\HOSTS             Host database
  43.      C:\XLN\HSTACC\PRINT.CFG      Database of Host printers for rpr.
  44.  
  45. Other (user-specific) files would be located in %EXCELAN%\PROFILE or
  46. %EXCELAN%\HSTACC.  The point is that all non-executable configuration
  47. files are located by the applications via a pointer to the LWP "root"
  48. directory stored in the "EXCELAN" environment variable.
  49.  
  50. Thus, all of the files found in %EXCELAN%\BIN40 can be placed in say;
  51. "SYS:PUBLIC/LWP" and be shared.  User specific files should be in a
  52. personal directory identified by the EXCELAN environment variable, but
  53. may be anywhere on any server.
  54.  
  55. Now.  All of this is relevant only after the TCP/IP protocol stack (and
  56. underlying ODI drivers) are loaded.  This is where the trickier (perhaps
  57. tedious) elements of server-based installation of LWP come in.  All of
  58. the ODI drivers, the IPXODI protocol stack, the NetWare shell, and the
  59. TCP/IP protocol stack, all get configuration info from the NET.CFG file.
  60. The TCP/IP stack gets the following (usually station-specific)
  61. information from the NET.CFG file:
  62.  
  63.               Protocol TCPIP
  64.                    ip_address     130.57.11.33
  65.                    ip_netmask     255.255.252.0
  66.                    ip_router      130.57.8.254
  67.                    tcp_sockets    8
  68.                    udp_sockets    8
  69.                    raw_sockets    1
  70.                    nb_sessions    4
  71.                    nb_commands    8
  72.                    nb_adapter     0
  73.                    nb_domain
  74.  
  75. In most cases, only the IP_ADDRESS field will be unique from PC to PC,
  76. though it is conceivable that other values here will be different as
  77. well.  The basic approach is to create a generic NET.CFG with *none* of
  78. this IP-specific information in it, and distribute it to all
  79. workstations' on floppy disk or include it in a diskless-boot image via
  80. DOSGEN.  A generic NET.CFG file might look like this:
  81.  
  82.               # Options from SHELL.CFG
  83.               SHOW DOTS = on
  84.               FILE HANDLES = 60
  85.  
  86.               Link Support
  87.                    Buffers 4 1500
  88.                    MemPool 2048
  89.  
  90.               Link Driver NE2000
  91.                    INT #1    5
  92.                    PORT      360
  93.                    Frame     Ethernet_II
  94.                    Protocol  IPX  8137  Ethernet_II
  95.               #    Frame     Ethernet_802.3
  96.               #    Protocol  IPX  0  Ethernet_802.3
  97.  
  98. Of course, this "generic" NET.CFG assumes that all PC's have NE2000's
  99. with the same hardware settings, but you get the idea.
  100.  
  101. The first ODI driver to read this NET.CFG file is the Link Support Layer
  102. (LSL.COM).  This example allocates a mempool and some buffers to the LSL
  103. (not required by IPXODI.COM) that will later be required by TCPIP.EXE.
  104. Also note that the "Link Driver NE2000" section has the requisite
  105. "Ethernet_II" frame format specified for IP.
  106.  
  107. After the LSL reads the NET.CFG file, all subsequent ODI drivers and
  108. protocol stacks will look for the NET.CFG file in the same drive and
  109. directory that the LSL found it in originally (although some drivers will
  110. instead read a NET.CFG that is located in the default directory at load
  111. time).  This means that the NET.CFG file with the node-specific TCP/IP
  112. values must be placed in the same location (in terms of drive letter and
  113. path) as LSL.COM was loaded from.  So, In the case of a diskless PC
  114. booting from a NetWare server, the BOOT image is placed in a virtual disk
  115. A:.  An autoexec.bat file for remote booting diskless workstations would
  116. look like this:
  117.  
  118.               prompt $p$g (etc...)
  119.               lsl
  120.               rplodi
  121.               ne2000
  122.               ipxodi
  123.               netx
  124.  
  125. Pretty basic, isn't it?  Well, on this diskless PC, the LSL has been
  126. loaded from a virtual image of drive A:\.  Thus, when TCPIP.EXE is
  127. loaded, it will look to the NET.CFG on A:\ because that is where the LSL
  128. originally found it (yes, future versions will have a command-line
  129. override for this).  So now the System Login Script or a subsequently
  130. executed batch file must be set up to map "A:\" to a directory on the
  131. server where a unique NET.CFG exists with the TCP/IP information for that
  132. node.  This would be an example of such a login script:
  133.  
  134.       IF "%P_STATION" = "00001B30B57B" then map root a:=vol1:node_1
  135.       IF "%P_STATION" = "00001B323EFB" then map root a:=vol1:node_2
  136.       IF "%P_STATION" = "00001B356BE2" then map root a:=vol1:node_3
  137.       DOS SET ADDR="%P_STATION"
  138.  
  139. You get the idea...  The final line would assign the PC's physical node
  140. address to the DOS environment variable "ADDR".  With this approach, one
  141. could leave all of the "IF...THENs" out of the System Login Script and
  142. construct a batch file that does the job:
  143.  
  144.       IF %ADDR%==00001B30B57B then map root a:=vol1:node_1
  145.       IF %ADDR%==00001B323EFB then map root a:=vol1:node_2
  146.       (etc).
  147.  
  148. Using this batch file approach, the System Login script does not need to
  149. force every machine through a long series of IF statements upon login.
  150.  
  151. One can easily apply this approach to machines having only floppy drives,
  152. though to conserve later access to the physical floppy, one may wish to
  153. load LSL, etc from a substituted drive G: or something:
  154.  
  155.               subst g: a:\net
  156.               g:
  157.               lsl
  158.               ne2000
  159.               ipxodi
  160.               netx
  161.               a:
  162.               subst g: /d
  163.               (etc)
  164.  
  165. Later, when it's time to load TCP/IP from the server...  A batch file or
  166. login script similar to those described above can map G: to the station
  167. specific directory.
  168.  
  169. As I said in an earlier posting, the installation of LAN WorkPlace on a
  170. server is not impossible, but it needs to be done manually and it takes
  171. someone who understands NetWare login scripts and perhaps batch file
  172. programming.  What I've described here works reliably, and in some cases
  173. may even be preferable to entering IP address into NET.CFG files at every
  174. node...
  175.  
  176. I should also note that this whole procedure can be simplified with the
  177. presence of a RARP server; if the IP_ADDRESS field in NET.CFG is all 0s
  178. or is blank, the TCP/IP stack will attempt to learn its' IP address
  179. via RARP.
  180.  
  181. Lastly, you can all imagine that we've given some serious thought about
  182. making all of this a much more manageable process in a future release of
  183. LAN WorkPlace for DOS :-).
  184.  
  185. Good luck with it,
  186. -- brian
  187. ____________________________________________________________________________
  188.          Brian Meek       Novell, Inc. - 2180 Fortune Dr. San Jose, CA 95131
  189. Internet Mail: brian@novell.COM                        Phone: (408) 473-8375
  190.  
  191.